As networks have proliferated, so too have the number of network-attached devices, such as servers, printers, bridges, routers and the like. Frequently these devices are geographically far removed from one another, even when attached to the same LAN, and managing such devices has become a major burden on network administrators. The Simple Network Management Protocol (SNMP) was designed to facilitate management of such devices from a central location.
SNMP allows a management software application running from a central location, such as a workstation, to query and or modify various objects associated with an SNMP-enabled device. Each SNMP-enabled device implements an SNMP agent, and the objects supported by any particular agent are defined in a source code listing referred to as a Management Information Base (MIB) listing. The MIB listing defines each object in terms of its attributes, such as its name, syntax, object identifier, access, status, and description. The management application reads the MIB listing to determine what objects a particular agent supports, whether the object can be read and/or written, the type of object (e.g., numeric, or string), and its object identifier. The object identifier is made up of a series of digits and periods, and is used to uniquely identify a particular object in an SNMP request from the management application.
The objects in a MIB are organized in a hierarchy which is established by the object identifier. The hierarchy is in the form of a tree, with each object being either a parent object, a child object, or a parent and child object. Parent objects are used to organize related child objects. For example, a group object is a parent object to certain child objects which somehow relate to the group object. Similarly, a table object is composed of rows, or sequences, of child objects. The hierarchy of such parent and child objects, however, is not easily determined from looking at the MIB listing, as the objects in a MIB listing merely follow one another sequentially.
To implement a MIB in an SNMP agent, or to determine what objects are implemented in a MIB, the MIB listing must be analyzed. Unfortunately, MIB listings can be very difficult to interpret because the definition of each object appears to be independent of every other object, and the parent/child relationship between the objects can be difficult to determine. MIB listings are created using a syntax referred to as Abstract Syntax Notation one (ASN.1), which requires that objects be defined in terms of its attributes, such as a name, an object identifier, a syntax, an access, a status, and optionally a description. Although optional, descriptions are widely used in practice to describe the purpose and use of the object and can be quite lengthy. The effect of this is that a single page of a MIB listing may contain the definition of only two or three objects. MIB listings frequently define hundreds of objects, resulting in MIB listings over 100 pages in length. Not only does such length make it difficult to locate a particular object, but can also make determining the hierarchy of the objects in the MIB very difficult. Although a text editor can be used to electronically search for the name of an object, it is presented without a context--that is without indicating where the object exists with respect to other objects.
For example, when examining a particular object in a MIB listing, either from a hard copy printout or from a computer screen, one cannot easily determine what objects are child objects of a particular object, or what attributes a parent object has. In fact, the parent object could be listed on a page 25 pages previous to the object of interest. Nor can one easily obtain an overall view of the hierarchy of the MIB. This is especially important when designing the layout of the MIB to ensure that the objects are implemented in a logical manner.